In telecommunication systems, particularly in mobile communication systems, very often measurements of the conditions, particularly quality, of an access medium (like radio access) is accomplished in order to detect problems or faults. Apart from such measurements, a terminal device, e.g. a user equipment as defined according to the LTE/SAE standard, can completely lose its connection to a network access node (in LTE, an evolved NodeB, eNB). It is often desired to obtain reports on such losses of connection, again in order to detect problems or faults.
For example, in 3GPP there is a work item (WI) called MDT (minimizing drive test). Within that WI the user equipment (UE) is asked to perform some measurements and report that to the network for analysis. Hence the need to perform costly drive test is minimized since the subscribers UEs can be used instead. For reporting these measurements, two alternatives exist, namely the “User Plane Solution” and the “Control Plane Solution”, as described in the 3GPP TSG-RAN WG2 working document Tdoc R2-095779, http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2—67bis/Docs/R2-095779.zip.
Most of these measurements are related to radio quality, and it is natural for the UE to report it with existing mechanisms for control plane (RRC reports). However for one important measurement it is not straight forward, the report of loss of connection or “drop report”. This report is used as a term for denoting the information an UE shall send to the network after the contact with a Base Station (i.e. a network access node) has been lost. Some information may include values such as position, radio measurements just before the drop etc.
One mechanism used in tracking such events is the so-called subscriber and equipment trace (S&E Trace), the structure of which is depicted in FIG. 1. The S&E Trace can be started towards several nodes in the LTE architecture. Once activated from a Network Management System (NMS) 11, each node records information and can forward this information (based on the included IP address in the activation message) to a Trace Collection Entity (TCE) 12 working as a central server. In the current 3GPP standard it is allowed to start an S&E Trace on a user equipment (UE) 13 and let the eNodeB (eNB) 14 configure the UE 13 to report some radio quality metrics, as is described in the following. Architecture, structure and functioning of S&E tracing are, for 3rd/4th generation mobile networks, described in 3GPP TS 32.421, 32.422, 32.423; Subscriber & Equipment Trace, and in 3GPP TS 32.441, 32.442, 32.443, 32.445; Trace management Integration Reference Point (IRP).
In the 3GPP TS 36.331, Radio Resource Control (RRC), the mechanisms for configuring the requested measurements is described for RRC reporting, i.e. for reporting over the control plane. As a short summary, the eNB can request measurements to be performed by the user equipment (UE) for radio quality aspects such as RSRP (Reference Signal Received Power) and RSRQ (Reference Signal Received Quality) in LTE (also in WCDMA similar mechanisms exist), then the UE will report the result of these measurement to the eNB that it is connected to. The eNB can then report this to the TCE if an S&E Trace is activated for that UE. An exemplary communication flow for control plane reporting is depicted in FIG. 2.
This type of control plane (RRC) reporting is advantageous in the respect that the UE only needs one reporting mechanism for radio related measurements.
However, one drawback of control plane reporting is the problem how to handle transferral of the report to the management system if a UE drops (i.e. loses connection), and reconnects to another cell. This problem is depicted in FIG. 3 and explained as follows:
For alternative 1 in FIG. 3, i.e. the UE 31 (which may correspond to the UE 11 of FIG. 1) connects to the same access node (eNB) 32 as before, the report can be communicated to the management system (represented by TCE 33) according to the same mechanism as when the call was not dropped. In this case, the UE 31 may report to the eNB 32 on the control plane which then may—as an option—process the data before transporting S&E Trace information to the TCE 33 (corresponding to TCE 12 in FIG. 1).
For alternative 2 in FIG. 3, i.e. the UE 31 connects to a different cell as before, e.g. to a different eNB 34, it is generally not known, or not in all cases known, how the information shall be reported. As one option, reporting may take place according to existing mechanisms to transport S&E Trace information to the TCE 33. This, however, is normally only possible if the new connection is to an access node (e.g. an eNB) 34 in the same network and the new access node (eNB) 34 has a trace activated. On the other hand, if the new access node (eNB) 34 has no trace activated, such a procedure may not necessarily work. Further, if the new access node 34 belongs to a different network or access technology (e.g. the previous access node 32 is an LTE eNB and the new access node 34 is a UMTS NodeB or a GSM base station), or even to a completely different network (PLMN), potentially of a different network operator, then there may be no possibility provided for handling the drop report.
Another mechanism of tracking is a solution in which the reports are communicated on the user plane (so-called “OMA reporting”). This mechanism is depicted in FIG. 4. As can be seen from FIG. 4, a report generated by the UE 41 (corresponding to UEs 11 and 31 of FIGS. 1 and 3) may be transmitted (indicated by the bar extending from the UE 41 to the OMA DM server 44) to a central server (OMA DM server) 44 in a way that is transparent for the nodes in between the UE 41 and the central server 44. For the eNB 42 and the Serving/Packet Data Network (S/PDN) gateway 43 the transmitted report would be seen and treated as any other user plane data. However, there is no interface to the NMS/TCE 45 to which reports should normally be communicated.
One advantage of this user plane reporting is that it can be done radio access technology (RAT) agnostic, since all the reports will be sent directly to the DM server 44 (and may potentially be forwarded to the NMS/TCE 45) for analysis.
On the other hand, this user plane reporting is disadvantageous as the implementation complexity for the UEs will increase since it will be required to support both the user plane and control plane reporting methods for the minimizing drive tests, and due to the fact that reports should be sent for other RATs than the one used for the reporting. Just as well, more data will be sent as reports from other RATs are included in the report. Further, there exists no interface yet between the OMA DM servers and TCE, so forwarding of a report to the NMS/TCE is not directly possible. As a still further aspect, it is difficult to correlate the measurements from the UE with the measurements from the network for the same call.
This is partly due to the fact that reporting according to the user plane solution becomes transparent to the eNB, i.e. the analysis and configuration of the reports is handled outside the eNB.
Generally, it is in some cases desirable that not only a central server, but the previous access node (eNB), i.e. the access node to which a UE was connected before the loss of connection, gets the drop report. By means of this report, an access node, e.g. an eNB, may find out a reason for the loss of connection and may possibly rectify or at least report the underlying problem. For instance, some transmission parameters may be adapted based on the drop report, antenna orientation may be adjusted or the like. Further, the size of the cell may be adapted, or even a new cell may be installed in case a coverage hole is detected.
However, it is apparent that with the user plane solution as described above there exist no means of communicating a drop report to the previous access node. The same applies for the control plane solution if a reconnect takes place at a different cell as before the loss of connection.